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Abstract 

In  the  information  age  era,  there  never  has  been  a  better  time  to  reflect  upon  the  fact 
that  information  in  itself  is  something  that  has  to  be  engineered.  Since  command  and 
control  is  a  cognitive  process  by  which  the  commander  gains  situation  awareness  and 
proceeds  to  deliberated  and  co-ordinated  action,  one  has  to  ask  himself  how  raw  data 
turns  into  actual  information,  and  eventually  knowledge  that  will  trigger  human 
understanding.  Furthermore,  the  question  arises  as  to  how  C4ISR  system  of  systems 
can  support  this  transformation  process.  Of  course,  this  is  no  magic.  Information 
systems  do  the  only  thing  they  are  good  at:  Working  on  large  amounts  of  data  at 
incredible  speed.  This  is  where  the  human  fails.  However,  data  must  be  aggregated  in 
such  a  way  that  it  results  in  information  that  conveys  operational  meaning  to  the 
commander.  This  is  where  information  technologies  alone  fail,  miserably.  The 
resulting  information  must  capture  the  semantics  of  the  commander’s  domain  of 
interest,  and  this  must  exist  prior  the  automated  data  transformation  process. 

The  exercise  of  capturing  the  semantics  of  a  certain  business  domain  (the  nouns, 
verbs,  adjectives,  etc.)  along  with  its  usage  guidance  (business  rules)  can  be  referred 
to  as  information  engineering  or  ontology  engineering.  Conducting  information 
engineering  activities  comes  in  support  of  the  definition  of  ontologies.  By  definition, 
an  ontology  is  an  explicit  formal  specification  of  how  to  represent  the  objects, 
concepts  and  other  entities  that  are  assumed  to  exist  in  some  area  of  interest  and  the 
relationships  that  hold  among  them. 

Broadly  speaking,  interoperability  can  be  achieved  for  systems  that  sit  on  top  of  a 
single  common  ontology,  or  for  systems  that  sit  on  top  of  distinct  ontologies  provided 
with  a  means  of  translation  between  the  crossing  domains.  An  example  of  the  first 
approach  is  the  Multilateral  Interoperability  Programme  (MIP)  that  provides  a 
common  ontology-oriented  solution  consisting  of  the  Command  and  Control 
Information  Exchange  Data  Model  (C2IEDM),  supporting  land-focused  joint  military 
operations.  In  the  next  2-year  phase,  its  focus  will  expand  to  full-blown  joint  military 
operations.  As  for  the  latter,  Defence  R&D  Canada  -  Valcartier  is  currently  working 
on  an  interoperability  solution  between  the  Canadian  Land  Forces  Command  System 


(LFCS)  and  the  United  States  Global  Command  and  Control  System  (GCCS).  Both 
systems  are  built  upon  distinct  ontologies  and  rely  on  a  proper  translation  mechanism 
to  achieve  operational  interoperability.  This  paper  describes  the  information 
engineering  process  (ontological  engineering)  that  must  take  place  in  order  to 
successfully  achieve  both  interoperability  solutions. 


Introduction 

The  current  conduct  of  military  affairs  prescribes  the  formation  of  coalitions  to 
achieve  missions.  The  geopolitical  context  of  today  and  the  globalisation  of 
communications,  notably,  force  us  to  think  of  the  world  as  a  global  village.  The  well- 
known  “butterfly  effect”  example  borrowed  from  the  chaos  theory  is  ever  more 
important  as  the  butterfly  flap  is  so  much  more  effectively  propagated  throughout  the 
world  than  it  was  years  ago.  Because  of  that,  military  organisations  do  no  longer 
operate  in  isolation.  They  must  operate  in  coalitions,  politically-wise  and 
operationally- wise.  Also,  since  information  operations  are  a  cornerstone  for  the 
effective  realisation  of  military  operations,  reliance  upon  information  systems  to 
gather,  organise,  provide  decision  aids  and  disseminate  information  is  increasing. 
Therefore,  increased  collaboration  between  national  systems  to  support  coalition 
operations  is  necessary.  We  refer  to  this  kind  of  collaboration  as  systems 
interoperability.  This  collaboration  scheme,  to  be  comprehensive,  must  be  subdivided 
into  several  levels,  one  of  which  is  the  establishment  of  a  common  basis  for  the 
semantic  concepts  that  will  be  shared  between  the  systems.  This  paper  relates  the 
authors’  experience  in  systems  interoperability  at  the  semantics  level,  following  2 
techniques  to  achieve  interoperability:  The  first  being  the  establishment  of  a  common 
shared  ontology  that  will  be  used  by  all  participants  who  want  to  participate  in  the 
coalition.  This  is  what  the  Multilateral  Interoperability  Programme  (MIP)  is  currently 
defining  with  its  MIP  solution.  The  second  technique  is  to  operate  a  translation 
between  the  shared  semantic  concepts  that  are  comprised  in  2  distinct  ontologies.  In 
this  case,  a  translation  between  the  Command  and  Control  Information  Exchange 
Data  Model  (C2IEDM)  [1]  and  the  Over-The-Horizon  Targeting  GOLD  (OTH-T- 
GOLD)  [2]  will  be  illustrated.  In  either  case,  it  will  be  shown  that  interoperability  can 
be  achieved  only  if  semantic  elements  are  common  to  both  systems  domains. 

Definition  of  Interoperability 

The  term  interoperability  being  widely  in  use  and  defined  in  several  ways,  this  paper 
will  focus  on  the  US  Joint  Publication  1-02  definition,  where  interoperability  is: 

“The  ability  of  systems ,  units ,  or  forces  to  provide  services 
to  and  accept  services  from  other  systems ,  units ,  or  forces , 
and  to  use  the  services  so  exchanged  to  enable  them  to 
operate  effectively  together.  ”  [3] 

The  Levels  of  Information  Systems  Interoperability  (LISI)  [4]  provides  a  5 -level 
hierarchy  for  interoperability  focused  on  4  attributes.  The  PAID  attributes 
(Procedures,  Applications,  Infrastructure  and  Data)  form  the  orthogonal  aspects 
vectors  that  qualify  systems  interoperability  while  the  5 -level  hierarchy,  ranging  from 
isolated  to  enterprise ,  qualify  the  degree  of  achieved  interoperability.  The  fact  that 


one  of  the  four  attributes  is  Data  shows  the  importance  that  semantics  play  in  the 
interoperability  scheme. 


The  NATO  C3  Technical  Architecture  [5]  also  defines  a  hierarchy  of  interoperability 
degrees,  ranging  from  unstructured  data  exchange  to  seamless  sharing  of  information. 
This  hierarchy  is  refined  into  sub-degrees  representing  functional  derivatives  of  the 
four  interoperability  degrees.  In  this  sense,  the  MIP  solution  aims  at  achieving 
interoperability  degree  2.h  (Structured  Data  Exchange/Data  Object  Exchange)  for  its 
human-interpretable  information  exchange  mechanism  and  degree  4. a  (Seamless 
Sharing  of  Information/Common  Information  Exchange)  for  its  systems-interpretable 
information  exchange  mechanism.  OTH-T-GOLD,  as  a  message  text  format  (MTF) 
allows  for  interoperability  degree  2.h. 

It  would  seem  that  attaining  higher  levels  of  interoperability  (either  from  LISI’s  or 
NC3TA’s  perspective)  is  desirable.  In  fact,  lower  levels  may  very  well  address  the 
operational  needs  for  systems  interoperability.  Since  also  that  higher  levels  require 
more  money  and  effort  to  achieve,  one  has  to  carefully  weigh  the  pros  and  cons  of 
adopting  the  interoperability  “nirvana”  while  in  fact  the  “right”  level  depends  on  the 
operational  concept  over-arching  the  need  for  interoperability.  The  operational 
concept  is  the  actual  driving  force  for  defining  the  level  of  interoperability  needed 
between  systems.  This  principle  becomes  a  prime  factor  for  information  engineering, 
either  when  defining  a  shared  common  ontology  (e.g.  the  C2IEDM)  or  when 
translating  between  2  ontologies. 


Ontologies:  definition  and  role 

Ontologies  have  received  increasing  interest  in  computer  science  and  information 
systems.  They  explicitly  encode  a  shared  understanding  of  a  domain  that  can  be 
communicated  between  people  and  application  programs  [6].  According  to  Gruber 
[7],  an  ontology  is  «  an  explicit  specification  of  a  shared  conceptualisation  ».  That 
means  that  it  formally  specifies  the  entities  that  exist  in  some  area  of  knowledge  and 
relationships  that  hold  among  them.  It  is  shared  in  that  it  represents  consensual 
knowledge  of  a  community  of  agents  that  adhere  to  the  definitions. 

In  the  literature,  ontologies  range  from  controlled  vocabularies  to  highly  expressive 
domain  models  [8]:  integrated  data  dictionaries  designed  for  human  understanding, 
taxonomies  organizing  concepts  of  a  domain  into  inheritance  hierarchies,  structured 
data  models  suitable  for  data  management,  and  finally  highly  expressive 
computational  ontologies.  Within  this  ontology  spectrum,  a  controlled  vocabulary  is  a 
finite  set  of  terms  with  unambiguous  definitions.  A  taxonomy  is  a  collection  of 
controlled  vocabulary  terms  organized  into  a  hierarchical  structure,  the  terms  being 
linked  by  generalization-specialization  relations.  A  thesaurus  is  a  networked 
collection  of  controlled  vocabulary  terms,  where  the  relations  between  terms  in 
thesaurus  hierarchy  are  interpreted  as  narrower-broader  relations.  Conceptual  models 
(e.g.  database  model)  are  also  part  of  the  spectrum  but  usually  concern  a  restricted 
domain  and  are  built  for  specific  applications.  Ontologies  add  more  expressiveness  in 
the  specification  of  relationships  between  concepts.  Formal  ontologies  use  a 
representation  language  to  specify  properties  and  constraints  of  concepts  that  can  be 
exploited  for  automated  reasoning  (inferencing). 


In  our  perspective,  an  ontology,  as  a  conceptualisation  of  a  domain,  explicitly 
captures  the  semantics  of  the  entities  in  that  domain.  It  comprises  the  definition  of 
concepts,  their  properties,  attributes,  relations,  as  well  as  constraints  and  axioms  that 
constrain  the  meaning  of  the  concepts  (disambiguation).  It  formally  specifies  the 
meaning  of  the  concepts  in  order  to  make  domain  assumptions  explicit  and  prevent 
errors  in  data  interpretation.  An  important  aspect  in  the  ontology  development  process 
is  to  explicitly  establish  relationships  that  exist  between  concepts.  De  facto 
relationships  between  concepts  in  ontologies  include  relations  that  link  a  concept  with 
more  specific  concepts  ( is-a/subsume  relation)  and  relations  that  link  a  complex 
object  to  its  constituents  (part-of/contains  relation).  Any  variety  of  relations  that  exist 
among  entities  should  be  specified,  for  example  causal,  functional  dependencies,  or 
temporal  relations. 

Due  to  their  formal,  expressive  and  shared  properties,  ontologies  constitute  domain 
models  that  can  be  reused  across  applications,  facilitating  knowledge  sharing  and 
reuse.  Moreover,  ontologies  facilitate  semantics  information  integration  and 
interoperability  between  heterogeneous  sources  at  a  high  level  of  abstraction.  They 
can  also  be  exploited  to  index  and  access  semi-structured  information  sources.  They 
facilitate  information  retrieval  over  collections  of  heterogeneous  and  distributed 
information  sources. 

Finally,  some  critical  issues  to  be  considered  regarding  ontological  engineering  are 
the  cost  of  developing  and  maintaining  ontologies,  and  the  fact  that  ontologies  should 
be  extensible  and  evolve  over  time. 

In  reaching  for  systems  interoperability,  2  solutions  are  possible  at  the  semantics 
level: 


1)  A  single  shared  common  set  of  semantic  elements  is  defined,  so  that 
disparate  systems  that  are  built  upon  it  achieve  semantics  interoperability 
at  once. 

2)  A  translation  mechanism  between  2  (or  more)  ontologies  is  defined  so  that 
minimal  semantics  interoperability  is  achieved. 


System  A  System  B 


System  A  and  B  share  no  semantics  elements. 
Therefore  interoperability  is  NOT  possible 


Semantics  Elements 


Shared  semantics  elements  capture 
equivalent  concepts  in  both  ontologies 
although  they  may  be  expressed 
differently.  Interoperability  is  possible. 


Figure  1:  Semantic-level  Interoperability 
Semantic-level  Interoperability 

It  is  argued  that  interoperability  at  the  semantics  level  is  not  always  possible.  Figure  1 
shows  an  illustration  of  this  as  2  systems  can  only  interoperate  if  they  share  some  of 
the  semantic  elements  their  distinct  ontologies  capture.  The  shared  elements  may  be 
expressed  differently  but  they  nonetheless  have  to  exist  in  both  ontologies. 
Consequently,  the  need  for  operational  interoperability  (e.g.  Navy  systems 
interoperating  with  Land  force  systems)  requires  that  the  semantics  of  the  information 
to  be  exchanged  exist  in  both  domains.  Whether  the  means  to  express  the  semantics 
are  the  same  or  different  does  not  change  the  need  for  the  concept  to  exist  in  both 
worlds.  The  military  realm  offers  a  strong  context  around  which  the  semantics  of 
different  domains  (air,  navy,  land,  joint)  often  overlap.  The  semantics  overlap  is  the 
actual  region  where  one  can  seize  the  opportunity  to  make  2  systems  talk  to  each 
other  at  the  same  semantics  level. 

The  question  arises  then  as  to  what  degree  of  semantic  overlapping  is  required  to 
achieve  interoperability  between  2  systems.  The  answer  lies  in  the  specification  of  the 
operational  need  for  interoperability.  Military  interoperability  occurs  when  different 
services  (air,  navy,  land,  joint)  in  a  combined  fashion  and  also  in  the  international 


context  (coalition).  The  reason  for  this  is  that  each  of  these  entities  develops  C2 
systems  that  suit  their  specific  needs.  Conducting  combined  and  coalition  operations 
give  a  strong  context  about  the  information  that  must  be  exchange  between  partners. 
This  in  turn  conditions  the  semantic  elements  that  must  exist  in  each  stakeholder’s 
ontologies.  Therefore,  the  operational  context  will  always  be  the  driving  force  and 
rationale  for  systems  interoperability. 

The  Multilateral  Interoperability  Programme 

The  goal  of  the  MIP  is: 

“to  achieve  international  interoperability  of  Command  and  Control 
Information  Systems  (C2IS)  at  all  levels  from  corps  to  the  lowest  appropriate 
level ,  in  order  to  support  multinational,  combined  and  joint  operations  and  the 
advancement  of  digitisation  in  the  international  arena,  including  NATO.  ”  [9] 

For  the  past  years,  the  MIP  community  has  been  working  on  the  establishment  of  its 
MIP  solution  that  is  two-fold: 

1)  Capturing  the  semantics  of  the  coalition  land  force  operations  and  the 
relationships  between  the  semantic  elements  of  the  battlefield.  This  resulted  in 
the  creation  of  the  C2IEDM  and  derived  artefacts,  leading  to  the  definition  of 
the  coalition  land  force  ontology-oriented  solution. 

2)  An  information  exchange  mechanism  (IEM)  that  would  enable  the  information 
flow  between  systems. 

To  achieve  this,  the  MIP  always  counted  on  a  strong  definition  of  the  operational 
concepts  for  land  operations  (Figure  lFigure  2).  The  MIP  Operational  Working  Group 
(OWG)  gathers  Subject  Matter  Experts  (SMEs)  and  defines  the  Information  Exchange 
Requirements  (IERs)  needed  to  conduct  land  operations.  These  are  then  decomposed 
into  Information  Content  Elements  (ICEs),  like  molecules  broken  into  atoms  of 
information.  The  ICEs  are  then  mapped  against  the  C2IEDM.  This  process  is 
necessary  to  prevent  duplication  of  semantic  elements  within  the  model.  The 
C2IEDM  is  then  enriched  with  business  rules  and  constraints  expressed  in  natural 
language  that  prevent  the  wrongful  utilisation  of  the  semantic  elements.  The  data 
model  in  itself  cannot  express  all  the  constraints  that  must  be  met  to  ensure  semantic 
integrity.  It  must  be  augmented  with  documentation  that  describes  all  possible  and 
forbidden  relationships  that  can  occur  between  semantic  elements.  This  is  why  the 
C2IEDM  always  come  with  its  main  documentation  and  annexes  [1].  Therefore,  the 
data  model  by  itself  does  not  constitute  a  formal  ontology.  However,  the  data  model 
augmented  with  its  documentation  form  a  comprehensive  informal  ontology  as  it  tries 
to  capture  every  semantic  aspects  of  its  domain  of  interest.  Generally,  the  MIP  data 
modellers  try  to  render  every  possible  aspect  of  the  C2IEDM  as  explicit  as  possible  so 
that  a  systems  developer  can  use  it  as  a  comprehensive  ontology-oriented  solution. 
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Figure  2:  Information  Exchange  Requirements  Process 


Mapping  the  OTH-T-GOLD  and  the  C2IEDM 

While  it  is  desirable  to  have  every  systems  sit  on  top  of  the  same  ontology,  and  also  to 
have  every  military  stakeholders  to  agree  upon  the  same  set  of  semantic  concepts,  it  is 
not  always  economically  feasible  to  systems  that  are  currently  fielded.  Therefore,  the 
fallback  solution  is  to  try  to  build  a  piece  of  code  that  will  translate  semantic  concepts 
from  one  ontology  to  another.  Defence  R&D  Canada  -  Valcartier  is  working  on  an 
interoperability  solution  between  the  US  Global  Command  and  Control  System 
(GCCS)  and  the  Canadian  Land  Forces  Command  and  Control  Information  System 
(LFC2IS).  GCCS  uses  OTH-T-GOLD  as  a  means  of  interoperability  between  its  own 
workstations  and  LFC2IS  sits  directly  on  top  of  the  MIP  solution  (C2IEDM  and 
IEM). 

Operational  Concept 

We  previously  mentioned  that  the  first  step  was  to  identify  the  operational  concept. 
Indeed,  recognizing  the  operational  concept  as  the  driving  force  that  prompts 
interoperability  is  the  key  and  allows  the  definition  of  the  information  exchange 
requirements.  In  this  exercise,  the  idea  was  for  the  land  force  to  be  able  to  inform  the 
navy  about  its  own  land  units  information  and  to  get  in  return  information  about  the 
navy  ships  information  (tracks).  The  operational  concept  is  to  gain  shared  awareness 
about  mutual  owned  information  (land  vs  navy)  so  that  missions  would  be  conducted 
with  a  degree  of  synchrony  that  was  before  only  possible  through  human  intervention. 


Information  Exchange  Requirements 


An  analysis  of  both  OTH-T-GOLD  and  C2IEDM  revealed  a  number  of  sets, 
attributes,  fields  and  values  that  would  convey  the  information  needed  to  support  the 
operational  concept.  For  example,  the  XCTC  message  in  OTH-T-GOLD  would  be  the 
main  vehicle  for  navy  information  to  the  land  component  while  several  attributes  of 
the  C2IEDM  would  fill  a  JUNIT  and  JPOS  so  that  land  information  would  populate 
the  navy  system.  It  is  a  very  long  and  fastidious  exercise,  but  a  necessary  one  to  align 
semantic  elements  of  both  ontologies. 


Semantics  Loss  and  Bi-directional  Information  Exchange 

We  know  that  for  interoperability  to  be  possible,  both  ontologies  must  comprise  some 
semantic  elements  that  they  must  share.  However,  information  elements  that  are  used 
to  express  these  semantic  elements  may  differ,  and  sometimes  they  differ 
significantly.  For  example,  both  OTH-T-GOLD  and  C2IEDM  are  capable  of 
expressing  aircraft  types.  However,  the  need  for  details  about  aircraft  types  differs 
from  the  land  component  to  the  navy  component.  A  “Mig  29”  in  OTH-T-GOLD  maps 
to  a  “fixed  wing  fighter”  in  the  C2IEDM.  However,  a  “fixed  wing  fighter”  in  the 
C2IEDM  corresponds  to  multiple  values  of  the  OTH-T-GOLD,  not  only  to  “Mig-29”. 
These  information  elements  cannot  be  exchanged  back  and  forth  between  the  systems. 
Therefore,  the  mapping  must  occur  between  information  elements  that  are  detailed 
enough  to  “nourish”  the  generic  information  elements,  provided  that  the  semantics 
necessary  to  support  the  operational  concept  is  still  conveyed  between  the  systems. 
We  define  this  as  an  “acceptable  semantics  loss”.  This  is  not  that  different  from  the 
jpg  image  file  format,  where  loss  of  information  is  accepted  to  result  in  smaller  files 
while  the  image  still  conveys  the  same  information  to  the  eye.  This  also  demonstrates 
that  information  elements  pushed  to  another  system  and  pulled  back  are  transformed 
in  the  process.  In  other  words,  bi-directional  information  exchange  is  often  impossible 
to  realize.  Does  this  mean  that  bi-directional  interoperability  is  impossible?  No!  The 
nature  of  information  exchanged  between  systems  can  be  asymmetric.  In  fact,  this 
asymmetry  is  desirable  as  it  prevents  this  kind  of  problem.  Of  course,  this  again 
should  not  contravene  with  the  operational  concept.  In  our  example,  it  made  sense 
since  land  information  belongs  to  the  land  system  while  navy  information  belongs  to 
the  navy  system.  It  was  never  a  question  whether  land  information  should  come  from 
the  navy  system  and  vice-versa.  In  other  words,  one-directional  information  exchange 
supported  bi-directional  interoperability  for  this  operational  concept.  One  who 
attempts  this  kind  of  interoperability  exercise  should  bear  in  mind  that  semantics  loss 
almost  always  arises  in  the  process,  so  it  is  better  to  clarify  which  system  bears  the 
“master”  information.  Otherwise,  it  may  lead  to  major  troubles. 


Conclusion 


Achieving  systems  interoperability  requires  that  there  is  sufficient  semantic  overlap 
between  systems’  respective  ontologies.  This  paper  described  the  steps  necessary  to 
realize  semantics  interoperability  either  by  adopting  one  and  only  one  ontology  or  by 
designing  a  means  to  migrate  from  one  ontology  to  another.  These  steps  were  labelled 
as  information  engineering.  Information  engineering  aspects,  characteristics  and 
particularities  were  illustrated  for  both  approaches.  In  either  case,  reaching  for 
systems  interoperability  makes  sense  only  if  it  supports  an  operational  concept  for  the 
exchange  of  information.  Keeping  this  in  mind,  the  development  of  a  single  shared 
ontology  will  stabilize  as  soon  as  the  operational  concept  is  supported.  The  same 
applies  to  the  harmonization  of  2  distinct  ontologies:  A  partial  mapping  constitutes  a 
success  if  the  over-arching  operational  concept’s  goal  is  met. 
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R*y  Goal  of  the  Presentation 


To  propose  a  reflection  on  the  conduct  of  activities 
leading  to  the  construction  of  an  ontological  basis, 
a  necessary  prerequisite  for  systems-to-systems 
interoperability  realisation. 


This  conduct  of  activities  will  be  referred  to  as 
information  engineering  within  the  context  of  this 
presentation. 
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R*y  Goal  of  the  Presentation 


•  Illustrate  the  Multilateral  Interoperability 
Programme  (MIP)  Data  Modelling  Working 
Group  (DMWG)  work  process:  The  construction 
of  the  C2  Information  Exchange  Data  Model 
(C 2 IE DM). 


->  Single  Shared  Ontology  Construction 

Illustrate  a  semantic  mapping  between  the 
C2IEDM  and  the  OTH-T-GOLD  specification. 

->  Distinct  Ontologies  Interface  Construction 
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Working  Definition  of  “Interoperability” 


«  The  ability  of  systems,  units,  or  forces  to  provide 
services  to  and  accept  services  from  other  systems, 
units,  or  forces,  and  to  use  the  services  so  exchanged 
to  enable  them  to  operate  effectively  together.  » 

Joint  Pub  1  -02 
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Working  Definition  of  “Interoperability” 


■V 


Operational  Context 


The  operational  context  is  the  driving  force 
for  systems  interoperability. 


Defence  R&D  Canada  -  Valcartier  •  R  &  D  pour  la  defense  Canada  -  Valcartier 


Working  Definition  of  “Ontology” 


An  ontology,  as  a  conceptualisation  of  a  domain, 
explicitly  captures  the  semantics  of  the  entities  in 
that  domain.  It  comprises  the  definition  of  concepts, 
their  properties,  attributes,  relations,  as  well  as 
constraints  and  axioms  that  constrain  the  meaning 
of  the  concepts. 


Semantic-level  Interoperability 
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Joint  Interoperability  with  a  Single  Shared 

Ontology  (C2IEDM) 
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Information  Engineering  Process 


•  Examine  the  operational  environment  from  an 
information  engineering  perspective. 


•  Create  an  operational  working  group  that  will 
comprise  experts  from  each  domain. 

•  Gather  Information  Requirements  (IRs)  and 
Information  Exchange  Requirements  (IERs). 


Break  IRs  and  IERs  into  Information  Content 
Elements  (ICEs). 

Ensure  a  shared  understanding  of  the  ICEs. 


Establish  the  C2IEDM  data  model  against  ICEs. 
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Figure  1.  IER  Evaluation  Process 
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f  \j  )  IERs  Sources 

L^ 


.  135  STANAGS 
inc.  5620  and  5621 

•  AD  80-50 

•  AAFCE  80-50 

•  CENT  AG  SOP 

•  NORTHAG  SOP 

•  ATP-35 

•  ATP-40 

•  ATP-45 

•  ADatP  -  3 

•  AIntP  -  3 

•  APP-9 

•  APP-6  &  6A 

•  SD  &  IC 


National 


Functional 

Models 


•  SOP’s  from  Nations 

•  US  Message  Text  Formats 

•  Message  Formats 

•  Message  Standards 

•  National  Doctrine 
•MCCRT 
•AIMS/IME 

•  BICES 

•  ADAMS 
•ACCS 
•DIGEST 
•MIDB 
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R*y  Requirements  for  the  C2IEDM 


•  Article  Y  (or  MIP)  IERs. 


•  Crisis  Response  Operations  (CROs)  IERs. 

•  Combined  Joint  Task  Force  (CJTF)  IERs. 
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Minimum  Exchange  Requirements 


First  Hostile  Act 


Intelligence  Report 
Intelligence  Request 
Intelligence  Summary 
Land  Intelligence  Report 
Enemy  Situation  Report 
Presence 

Own  Land  Force  Situation 
Report 


Rule  of  Engagement 
Request 


Rule  of  Engagement 
Implementation 

Commander’s  Assessment 

NBC  Chemical  Downwind 
Report 

NBC  Effective  Downwind 
Report 

NBC  1  and  3 

Operational  Plan/Order 

Fragmentary  Order 

Logistic  Situation  Report 
Land  Forces 

Logistic  Assessrep  Report 
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Minimum  Exchange  Requirements 


Casualty  Evacuation  Request 

Personnel  Report 

Medical  Assessment  Report 

Medical  Situation  Report 

Non-Nuclear  Fire  Planning 

Fire  Mission  Report  and 
Command 

Artillery  Fire  Unit  and  Status 
Barrier  Report 
Obstacle  Report 
Reserved  Demolition  Order 


Scatterable  Minefield 
Warning  /  Request  /  Report 

Weapons  Control  Order 

Air  Defense  Report 

Airspace  Control  Order 

Air  Attack  Warning 

Air  Request 

Helicopter  Site  Landing 
Report 

Helicopter  Request 

Joint  Air  Attack  Team 
Mission  Order 

Civil/Military  Operation 
Order 
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Minimum  Exchange  Requirements 


•  Meaconing,  Intrusion, 
Jamming,  Interference 
Warning  Report 

•  EW  Request/Tasking 
Message 

•  CCIS  Status  Report 


Communications  Situation 
Report 

Radio  Frequency  Request 
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CROs  Exchange  Requirements 


Arrest  Report 
Border  Crossing 
Camps 

Civil  Military  Operations 
Confiscated  Equipment 
EOD  Incident 
Holdings  Parties 
Host  Nation  Support 
Incident  Report 
Mass  Graves 
Meteorology 


•  Personnel  Identification 

•  PSYOPS 

•  Displaced  Persons 

•  Refugees 
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R*y  CJTF  Exchange  Requirements 


Air  and  Sea  Picture 
Domain 


Joint  Intelligence 
Domain 


•  Control  Measures 

•  Fire  Support 

•  Ground  Picture 

•  Unit  and  Facility 

Logistics 


•  Air/Marine  Intelligence 

•  Human  Intelligence 

•  Joint  Electronic  Warfare 

•  Collection  Management 

•  Targeting 

Domain 


•  Force  Maintenance 

•  Force  Movement 

•  Medical  Support 

•  Logistic  and  Combat 
Service  Support 
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Linking  ICEs  with  IERs 

L^ 

IER 


I 


has  an  element 


indicated  via 


IER-ICE-ASSOCIATION 


lER-short-name-id  (FK) 

ICE-id  (FK) 

lER-IGE-ASSQCIATIQN-inde 


lER-short-name-id 


lER-name-text 

lER-purpose-text 

lER-priority-code 

lER-staff-code 

lER-source-code 

IER- reference-text 

IER-priority-ranking 


SUBECT-AREA 


SUBJECT-AREA-id 

is  reference  for 

SUBJECT-AREA-text 

] 

SUBJECT-AREA-ICE-ASSOCIATION 


I 


ICE-id  (FK) 

SUBJECT-AREA-id  (FK) 


S  U  B  J  E  CT -AR  E  A- 1 C  E  -  ASSOCI  ATI  ON-a  na  lyst-tes  :t 


is  contained  in  an  IER 


QFS-CQMMENTS 


as  indicated  by 


ICE-id  (FK) 

OPS-COMMENTS-index 


OPS-COMMENTS-evaluator-code 
QPS-COMMENTS-date 
OPS-COMMENTS-status-code 
OPS-COMMENTS-necessity-code 
OPS-CGMMENTS-text 

ICE-MAPPING 
' ICE-id  (FK) 

ICE-MAPPING-index 

ICE-MAPPING-evaluator-code 
ICE-MAPPING-date-lext 
IGE-MAPPING-status-code 
IGE-MAPPING-category-code 
ICE-MAPPING-evaluation-text 


ICE 


is  assigned  a  topical 


classification  through 


I 


is  assessed  as  provided  ir  ICE-id 


ICE-ASSOCIATION 


ICE-name-text 
I  CE-defin  ition-texl 
I C  E-p  re  ce  d  e  n  ce-cod  e 
I  CE-a  na  lyst-com  me  nt-texl 


Primary-ICE-id  (FK) 
Secondary-ICE-id  (FK) 


is  evaluated 
against  LC2  in' 


j 


|  may  serve  as  primary  through 
may  be  deemed  secondary  through 


may  have  an  associated  may  have  ICE-DOMAIN-SUBTYPE 


ICE-CONDITION 

ICE-id  (FK)  , 

ICE-CONDJTION-inde>*- 


may  have  a  qualifying 


ICE-DOMAIN 

ICE-id  (FK) 
ICE-DOMAIN-index 


ICE-CONDITION-lext 


ICE-DOMAIN-logical-value-text 
ICE-DOMAIN-value-definition-te)dt 
ICE-DOMAIN-physical-value-text 


ICE-id  (FK) 

ICE-DOMAIN-index  (FK) 
ICE-DOMAIN-SUBTYPE-index 

ICE-DOMAIN-SUBTYPE-logical-value 
ICE-DOMAIN-SUBTYPE-value-definitioh 
ICE-DOMAIN-SUBTYPE-physical-value 
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R*y  Classifying  ICEs  into  Subject  Areas 

L^ 


Organisation 

Location 

Rules  of  Engagement 

Materiel 

Control  Features 

Holdings 

Status  of  Items 

NBC  defensive 

Activity 


•  Capability 

•  Objects 

•  Candidate  Target 

•  Facility/Installation 

•  Person 

•  Geographic  Feature 

•  Medical 

•  Weather 

•  Communications 
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Pros  and  Cons  of  a  Single  Shared  Ontology 


Pros 


Cons 


Only  1  interface  to  write  to 
achieve  interoperability 
with  the  community. 

100%  shared  understanding. 

Increased  maintainibility. 


•  You  have  to  spend  energy 
to  have  everybody  agreeing 
upon  a  concept. 

•  Legacy  systems  can  hardly 
adapt. 
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Joint  Interoperability  using  Different 

Ontologies 


TXjij  Designing  the  Meat  Grinder 

•  Conduct  a  Semantics  Translation  Analysis. 

•  Identify  the  Systems  Entry  Points. 

•  Develop  the  grinder  that  will  speak  both  languages. 
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Semantics  Translation  Analysis 


•  Examine  the  operational  context  under  which  the 
bilateral  information  exchange  will  take  place. 


•  Identify  Information  Requirements  (IRs)  and 
Information  Exchange  Requirements  (IERs). 

•  Break  them  into  ICEs  and  verify  if  their  semantics 
are  captured  in  both  ontologies. 


Make  the  connection  between  the  data  elements. 
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Practical  Example 


•  LC2IEDM  OTH-T-GOLD  (GCCS) 


-  Operational  Context:  Land/Navy  Joint 
Operations. 

-  IERs:  Pushing  Land  Units  Positions  and  Pulling 
Maritime  Tracks. 


•  No  bi-directional  pulling/pushing 
(assymetrical  exchange). 
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2)  ICEs  Semantics  Existence  in  both  Models 

L^ 


OTH-T  GOLD  CTC  Set  Fields  and  LC2IEDM/ODB  Attributes  Correspondence 

POS/JPOS  Field 

LC2IEDM  5.3 

ODB 

Comment 

1-  DATE-TIME  GROUP 

report  i  ng-data-abs  ol  ute-t  i  m  i  ng-effect  i  ve-date 

reporti  ng-data-absol  ute-t  i  m  i  ng-effect  i  ve-date 

2-  MONTH 

3-  LATITUDE  OF  CENTER 

absolute-point-latitude-coordinate 

absolute-point-latitude-coordinate 

4-  LONGITUDE  OF  CENTER 

absolute-point-longitude-coordinate 

absolute-point-longitude-coordinate 

5-  SENSOR  CODE 

reporting-data-source-type-code 

reporting-data-source-type-code 

Proposition  to  skip  this  field  because  there 
is  too  much  semantic  disparity  between 
OTH-T  GOLD  and  the  LC2IEDM. 

7-  LENGTH  OF  SEMI-MAJOR  AXIS 

object-item-location-accuracy-quantity 

organisation-point-accuracy-quantity 

9-  COURSE 

object-item-location-bearing-angle 

organisation-point-bearing-angle 

10- SPEED 

object-item-location-speed-rate 

organisation-point-speed-rate 
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R*y  Mapping  Data  Elements 


OTH-T  GOLD  Rev  B  and  C  Entry  List  59 

LC2IEDM  5.3 

Country 

Code 

Country 

Code 

Exercise  NATO  Force 

OT 

Not  otherwise  specified 

NOS 

Exercise  Neutral  Country 

ZC 

Not  otherwise  specified 

NOS 

Exercise  Neutral  Force 

zz 

Not  otherwise  specified 

NOS 

German  Democratic  Republic 

GC 

Not  otherwise  specified 

NOS 

Germany 

GM 

Germany,  Federal  Republic  of 

GE 

Germany,  Berlin 

BZ 

Not  otherwise  specified 

NOS 

Germany,  Federal  Republic  of 

GE 

Germany,  Federal  Republic  of 

GE 

Ghana 

GH 

Ghana 

GH 

Gibraltar 

Gl 

Gibraltar 

Gl 
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Pros  and  Cons  of  Designing  a  Meat  Grinder 
between  2  Ontologies 


Pros 


Cons 


•  Low-cost  solution. 

•  Usually  easier  to 
implement. 


Information  Analysis  is 
usually  simpler. 

Offer  a  possible 
interoperability  solution  for 
legacy  systems. 


Semantics  disparities 
between  ontologies  (almost 
always). 

Symetrical  exchange  is 
almost  always  a  big  no-no. 
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Lessons  Learned  and  Conclusion 


•  Ontology  translations  always  suffer  semantic  loss. 
However,  this  is  acceptable  if  and  only  if  the 
operational  context  is  supported. 

•  OTH-T-GOLD  is  not  an  ontology. 

•  The  human  is  part  of  the  ontology. 
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Questions??? 


Questions??? 


IL 


Questions??? 


Questions??? 


